Closing as requested/reported by Charles:

16:43 < cahewson> mika: mark #1132 as resolved by using ext3 file systems for
live-rw, home-rw. live-sn, home-sn are still testing in progress.

Thanks,
-mika-

On Sun, 15 Jan 2012, Michael Prokop wrote:

>
> Michael Prokop <mika@grml.org> added the comment:
>
> Hi Charles,
>
>> I normally use mkfs.vfat but used 1 & 2 below from
>> earlier attemt to get usb directly bootable.
>
> Ah ok. Can you please retry with ext3 filesystem?
>
>> Is their a debug=? option that would save the detailed
>> logs on successful boot?
>
> If you're booting with the debug boot option (being debug=vc or debug=1) then
> the logs should be available as /var/log/live.log or so after booting finished.

attached log I had only been looking in /tmp.
>
> By the way, don't worry about the screen capture for now, because the
> issue seems to be related to the vfat file system according to your logs.
> Let's see whether it works for you with ext3 (because it does for me).
>

system boots all the way up but doesn't seem to have uncomtressed cpio.gz 
and has left the two files from usb in / at shutdown (i believe) it wrote 
uncompressed folders to usb
> Thanks,
> regards,
> -mika-
>
> _____________________________________
> GRML issue tracker <bts@bts.grml.org>
> <http://bts.grml.org/grml/issue1132>
> _____________________________________
>
Charles
-- 
Charles Hewson <cahewson@eskimo.com>
Seattle, WA. U.S.A.

Hi Charles,

> I normally use mkfs.vfat but used 1 & 2 below from
> earlier attemt to get usb directly bootable.

Ah ok. Can you please retry with ext3 filesystem?

> Is their a debug=? option that would save the detailed
> logs on successful boot?

If you're booting with the debug boot option (being debug=vc or debug=1) then
the logs should be available as /var/log/live.log or so after booting finished.

By the way, don't worry about the screen capture for now, because the
issue seems to be related to the vfat file system according to your logs.
Let's see whether it works for you with ext3 (because it does for me).

Thanks,
regards,
-mika-

Had other committments this am but here is 15:00 update from seattle.
This testing based on GRML32_testing-20120114, i386.

On Sat, 14 Jan 2012, Michael Prokop wrote:

>
> Michael Prokop <mika@grml.org> added the comment:
>
> * Charles A. Hewson wrote in grml's BTS on 20120114 / 01:29:
>
>>> Hmmmmm, did you use the "persistent" option from the boot menu which included
>>> the "persistent=nofiles" boot option setting? If so can you please retry with
>>> just "persistent" (so drop the =nofiles)?
>
>> Persistent with nofiles boots. However, nothing from cpio.gz appears after
>> boot. Adding debug=1 and log with nofiles didn't provide clues. Files
>> in cpio were created 1/9/2012.
>
> Ok
>
>> Per http://lists.debian.org/debian-live/2011/11/msg00148.html (nofiles &&
>> cryptsetup) were | are | will go away. Since I could not discern if code
>> pushed in email got into grml I droped "=nofiles".
>
> Yeah, I stumbled upon this issue on my own today and updated
> grml-live templates so they don't use persistent=nofiles any longer
> but just "persistent"
>
>> If the code ref. in email is in grml this may be issue in up stream. And,
>> our wiki page on persistent needs more work. I would draft it after I
>> verify how it now works.
>
> Yeah, the wiki page on persistent definitely needs some love!
> Would be great if you could help us on improving that.
>
>> Persistent alone (with debug=1 & log only) drops to busybox shell (screen
>> print attached). I copied live-boot.log at that point. After <ctrl>D machine
>> locks up also attached.
>
> Thanks for that, this definitely helps:
>
>  blkid -o value -s TYPE /dev/sdb4
>  FSTYPE=vfat
>  [...]
>  mount: mounting aufs on /root/ failed: Numerical argument out of domain
>
> This matches exactly http://bts.grml.org/grml/issue1079 which I
> tried to reproduce but couldn't with a recent autobuild ISO.
>
> Could you please try again with persistency using on an ext3
> filesystem instead of vfat? Do you have the mkfs.vfat command line
> available you used for creating the file system?

I normally use mkfs.vfat but used 1 & 2 below from earlier attemt to get 
usb directly bootable.

live-boot.log is under same conditions as 20120106 but with 20120114.

grml.log.2120114 doesn's show much; console warnings about not finding 
persistent root filesystem and not mounting snapshots. I will not have 
access to screen capture on virtualbox instance until monday seattle 
time. Is their a debug=? option that would save the detailed logs on 
successful boot?

> > It would be very interesting to know whether you can reproduce this
> issue with the 2012-01-14 daily ISOs that are supposed to be
> available during the next few hours.
>
>> P.S. My goal is to have b43 firmware into system early for machine where
>> that is only outside link. And, when luks persistent is automounting
>> eliminate second usb for encrypted /etc & /home.
>
> nice :)
>
> Thanks, Charles!
>
> regards,
> -mika-
>
> _____________________________________
> GRML issue tracker <bts@bts.grml.org>
> <http://bts.grml.org/grml/issue1132>
> _____________________________________
>

Charles

-- 
Charles Hewson <cahewson@eskimo.com>
Seattle, WA. U.S.A.

* Charles A. Hewson wrote in grml's BTS on 20120114 / 01:29:

> > Hmmmmm, did you use the "persistent" option from the boot menu which included
> > the "persistent=nofiles" boot option setting? If so can you please retry with
> > just "persistent" (so drop the =nofiles)?

> Persistent with nofiles boots. However, nothing from cpio.gz appears after 
> boot. Adding debug=1 and log with nofiles didn't provide clues. Files 
> in cpio were created 1/9/2012.

Ok

> Per http://lists.debian.org/debian-live/2011/11/msg00148.html (nofiles && 
> cryptsetup) were | are | will go away. Since I could not discern if code 
> pushed in email got into grml I droped "=nofiles".

Yeah, I stumbled upon this issue on my own today and updated
grml-live templates so they don't use persistent=nofiles any longer
but just "persistent"

> If the code ref. in email is in grml this may be issue in up stream. And, 
> our wiki page on persistent needs more work. I would draft it after I 
> verify how it now works.

Yeah, the wiki page on persistent definitely needs some love!
Would be great if you could help us on improving that.

> Persistent alone (with debug=1 & log only) drops to busybox shell (screen 
> print attached). I copied live-boot.log at that point. After <ctrl>D machine 
> locks up also attached.

Thanks for that, this definitely helps:

  blkid -o value -s TYPE /dev/sdb4
  FSTYPE=vfat
  [...]
  mount: mounting aufs on /root/ failed: Numerical argument out of domain

This matches exactly http://bts.grml.org/grml/issue1079 which I
tried to reproduce but couldn't with a recent autobuild ISO.

Could you please try again with persistency using on an ext3
filesystem instead of vfat? Do you have the mkfs.vfat command line
available you used for creating the file system?

It would be very interesting to know whether you can reproduce this
issue with the 2012-01-14 daily ISOs that are supposed to be
available during the next few hours.

> P.S. My goal is to have b43 firmware into system early for machine where 
> that is only outside link. And, when luks persistent is automounting 
> eliminate second usb for encrypted /etc & /home.

nice :)

Thanks, Charles!

regards,
-mika-

On Fri, 13 Jan 2012, Michael Prokop wrote:

>
> Michael Prokop <mika@grml.org> added the comment:
>
> Hmmmmm, did you use the "persistent" option from the boot menu which included
> the "persistent=nofiles" boot option setting? If so can you please retry with
> just "persistent" (so drop the =nofiles)?
>
> ----------
> status: unread -> need-eg
>
> _____________________________________
> GRML issue tracker <bts@bts.grml.org>
> <http://bts.grml.org/grml/issue1132>
> _____________________________________
>

Persistent with nofiles boots. However, nothing from cpio.gz appears after 
boot. Adding debug=1 and log with nofiles didn't provide clues. Files 
in cpio were created 1/9/2012.

Per http://lists.debian.org/debian-live/2011/11/msg00148.html (nofiles && 
cryptsetup) were | are | will go away. Since I could not discern if code 
pushed in email got into grml I droped "=nofiles".

If the code ref. in email is in grml this may be issue in up stream. And, 
our wiki page on persistent needs more work. I would draft it after I 
verify how it now works.

Persistent alone (with debug=1 & log only) drops to busybox shell (screen 
print attached). I copied live-boot.log at that point. After <ctrl>D machine 
locks up also attached.

Charles

P.S. My goal is to have b43 firmware into system early for machine where 
that is only outside link. And, when luks persistent is automounting 
eliminate second usb for encrypted /etc & /home.

Thx again for all your hard work,
Charles
-- 
Charles Hewson <cahewson@eskimo.com>
Seattle, WA. U.S.A.

Hmmmmm, did you use the "persistent" option from the boot menu which included
the "persistent=nofiles" boot option setting? If so can you please retry with
just "persistent" (so drop the =nofiles)?

Hi all,
I am working from grml32_testing-20120106 as issue 1126 is fixed there.

Background steps on 32 bit box:

1 create vfat usb stick mkdiskimage -4 /dev/fd0 0 64 32.
2 add dos label with dosfslabel.
3 reboot grml , usb shows in blkid and /mnt/live-rw. 
4 copy /live/live-snapshot... to /mnt/live-rw per on screen instructions
   from live-snapshot.
5 unmounted /mnt/live-rw and rebooted selection persistent from grml
   menu.
6 cpio.gz has size but everything in /root and /home/grml either was not
   uncompressed or was overlaid later in boot sequence.
7 added test files to /root and /home/grml, re-did snapshot and 4-6 above.
8 added file live.persistent to /mnt/live-rw and re-did 4-6 above.
9 rebooted and selected debug from grml menu. did tab and added persistent
   to cmdline. kernel panic in live-bottom and machine locked up. reset
   box.

On win 7 box with current virtualBox:

1 took usb and, created virtual machine similar to 32 bit box, recreated
    problem to gather attached files.
2 on this box also attempted by adding "debug=1 log" to persistent menu
   line so am confident it is not typing error.

Thanks,
Charles



-- 
Charles Hewson <cahewson@eskimo.com>
Seattle, WA. U.S.A.