Some ideas for the next round of antix2usb, following on from this post, post36679.html#p36679.


I had not intended to start with this one, but as it happened since making the above post it seems a reasonable candidate. It happened very recently on a USB stick created just to look in to potentential ideas.

On a USB v2 stick, an antiX-13.2-Stable-Live system was created with a single partition via antix2usb. Persisetent root and home were created and the system rebooted with them in use. For some unidentified reason, during the session the system froze with an unresponsive keyboard and mouse. After a considerable time, the system showed no signs of becoming usable, so the only option was to switch of the power.

Upon rebooting from the stick, unsurprisingly, the boot process reported problems with sdb1 (the stick). A file system check was run automatically and reported errors that it would not fix. The system paused asking whether to continue, power off, or reboot. From this position, if it is possible to continue the boot process to completion, the things that need to be checked and fixed are in use so it cannot be done.


SUGGESTION
Provide a means to fix the problems at the point of notification.

A fourth option might be appended so the question at the pause becomes, continue, fix, power off, reboot. When the option to fix is selected, display a descriptive guide of how to conduct the fix (fsck?). Rather than being a brief message it will be beneficial to offer help beyond that provided by the output of command --help. I see the content of the message being targeted at a novice or low skilled user who otherwise might be stymied. A skilled user is more likely to have knowledge and experience than a novice.


CONTINUING
The system was rebooted using different media (not the stick) then the stick manually checked, repaired and reported clean by fsck.

The system was rebooted using the stick. Again the boot failed with unfixed errors and paused at the same point as previously. This time problems were reported on homefs rather than sdb1.

With sdb1 fixed and clean, rootfs not reporting problems, how does one fix problems on homefs? Depending upon which boot menu option is selected, at completion of the boot process, it is either automatically in use, or not in use but existing only as a compressed file. In either case it is unavailable to be fixed by fsck.

antiX is infrequently run from USB here, so I might have missed something. Other than possibly recreating homefs (adjusting its size?), the fix is not obvious.

Just to mention what I do in these situations. I know it does not address you statement though.

I boot a live seesion and run checks on the file system using garted in a live session to fix a corrupted flash drive.

Then boot it OK.

I know these/yours are suggestions for the next release. So I am just posting alternative ways to get by in a situation like this,

Now back to on topic. Sorry.

@rokytnji No need for apologies, your posts are always worth reading.

Putting aside the idea of providing timely and helpful info when booting the stick...

I think your use of gparted is doing the same thing as my use of fsck. After the uncontrolled power-down, booting from the stick, reported a problem with sdb1 i.e. the file system on the single partition of the stick. Until this was fixed with fsck (or gparted in your case) a second level problem was masked. The boot process never reached it, because it always saw the problem with sdb1 first.

After fixing sdb1, the boot process continues far enough to recognize and report the problem with homefs. This cannot be fixed in the same way.

When fixing sdb1, homefs is seen as a single file rather than a file system, so is not repaired. After repairing sdb1, the boot process is eventually able to proceed to the point where it checks homefs as a file system and reports that it will not repair the problems. If the boot is able to continue and complete (desipite the problems) homesfs is either in use and cannot be repaired or not in use and cannot be repaired because it is seen by antiX as a file rather than an umounted file system.

I think the basic difference between our methods is that you were working with a single problem at stick fs level. I was working with two problems. One at stick fs level and the other contained within an fs within a file within the fs on the stick.

Clear as mud.

I should keep my mouth shut. But my method worked on persistent puppeee linux where a save file of changes also sat and was checked and gone through since the save file was a ext2 compressed file also.

I probably don't know what the hell I am talking about though since puppeee and antix run persistent different.
Like apples vs oranges.

Just jaw jacking so don't mind me folks.

rokytnji wrote:I should keep my mouth shut.

In my view its far better if you rokytnji don't do that. Over the last few years I've learnt a lot from what you chip into this forum. Like I mentioned above, I don't use antiX-Live-USB as much as others, so it may be that I am talking out of ...errrr... the back of my head on this matter.

Here are some issues I'm aware of that I was planning to tell the dev about. There are listed rough in order of priority:

1. IMO the biggest problem by far is there are virtual no error messages in the GUI version and it will blithely lie and say"mission accomplished" when it's not. I have solutions to this problem that I want to pass on to the dev.
2. Another problem is that it bombs out (saying"mission accomplished") if there is a space in the pathname to the usb (or iso file, or both?). This can happen frequently on systems that mount usbs by label and there is a space in the label.
3. Antix2usb relies on very specific versions of certain programs which makes it needlessly unportable. If it was a little more flexible about what versions it uses then it could work on a wide variety of Linux systems and it would make sense to distribute it alongside the iso files. Again, I have an easy fix for this.
4. With just a little more work it could create a LiveUSB from a running live system with no need for an .iso file. This would be extremely convenient. There have been numerous complaints/requests about this.
5. This brings up another issue. While I love the extremely simple and elegant GUI interface, IIRC, the simplicity makes it hard to do some things that would make a lot of sense. Ideally the source and the destination would be chosen before things like persistence files, optional swap partition, and optional fat32 partition were chosen. Also before the grub/syslinux choice is presented.
6. If we know the source and the destination first, then we would know how much size is available and we could make reasonable default choices for the size of rootfs, homefs, swap, and fat32 partition.
7. Finally, there have been repeated requests for an easy way to create an iso file from a working live system. Perhaps antix2usb is not the perfect place for this feature but it makes sense to add it here than to make a stand-alone program for it.

BitJam wrote:Here are some issues I'm aware of that I was planning to tell the dev about. There are listed rough in order of priority:

Thanks for the list, it covers a lot of the ground I had in mind.


Comments on list items

1. I'm not sure its the biggest problem. I agree it is a highly important one. From a usability perspective, it is closely linked to item 5.
2. This often crops up for anyone who stores the ISO on a remote share that has a space in the mountpoint path or share share name
3. -
4. Is it correct to infer from the phrase"...create a LiveUSB from a running live system..." a system booted by whatever method, rather than exclusively from a live CD/USB? If yes, capturing the updated and upgraded system state is indeed attractive.
   
   I see this as extending the capability of antix2usb rather than becoming its only mode of operation. By retaining the ability to work from an ISO, it remains the most convenient way of producing an as-shipped version of antiX
   
   Additionally this is closely linked to items 7 and 10
5. In general terms I am a fan of targeted simplicity. By this I mean being immediately understandable to, and directly usable by a particular audience. For this utility, perhaps an archetypal novice, inexperienced antiX user. After all, more experienced users can usually rely on their greater knowledge, whereas the novice cannot.
   
   The purpose of every GUI stage/window should be as intuitive and obvious as possible to the target group. Technical terminolgy should be avoided wherever possible. Descriptions and guidance in each window should focus on its outcome i.e. what the user is trying to achieve, rather than the name, label, and process that the developer is familiar with.
   
   It is probably most effective when it forms part of the planning stages of the utilty rather than being addressed after it is produced.
   
   It is not easy to do.
6. The defaults offered are very important. This is particularly the case when any user operates the utliity for the first time. This is likely to be when the user makes an assessment of whether it is of any value to them. The old saying"you never get a second chance to make a first impression" is applicable here. Perhaps consideration might be given to having an uncluttered default interface providing few choices for users with simple needs. A button might be provided to display a YAD input form for users wanting to employ optional items.
   
   See item 11
7. The last time I recall feeding this into the development round was prior to 13.2 (maybe 13.1).
   I view this functionality as associated with item 4. It is particularly relevant for hardware that is unable to natively boot from USB and/or has slow v1 USB ports. For such hardware an ISO that can be burned to CD is a good choice. Also this fits with well with an antiX goal of extending the life of otherwise redundant kit.

Aditional Items

• 8. Although the opening post of this topic is not directly an antix2usb matter, it is so closely related that it is OK to include it in the present round of discussions.
  
  
  9. Any reworking of antix2usb should automatically handle the unmounting of all file systems on a target USB stick.
  
  
  10. Items 4 and 7 to include an option to produce an outcome that includes the standard antiX installation routines. When selecting this option, the result should not contain anything that is specific to the hardware on which it is produced e.g. video, networking, disk partitions etc. It should contain updates/upgrades/apps that are not tied to the hardware. The standard antiX installation routines should be retained and available.
  
  
  11. In item 6, the optional input window might include the ability to work with existing file systems created by the user. This might allow performance tailoring to be employed such as that mentioned below.
  post34834.html#p34834

Edit
Amended item 10. The original wording could be interpreted as producing physical media. The actual intention is to produce an environment that optionally includes the standard antiX installation routines.